Automation systems for automated production facilities and other applications have a multiplicity of sensors and actuators, these frequently being referred to in summary by the term “automation components”. The automation components are connected to one or more central devices, which are often referred to as “automation controllers” or else as “CPUs” for short. In this case, the connection is usually made by means of what is known as a bus system, that is to say by means of a data line to which a multiplicity of automation components and automation controllers can be connected. An automation controller usually has the task of controlling the automation components. This means that an automation controller receives and processes measured values and state information from the sensors, and in return generates commands (control information) for the actuators and transmits them to these. In addition, an automation controller can also receive and process status information from the automation components, said status information providing information about the state of the respective automation component itself, for example about faults, operating state, etc.
Other parts of customary automation systems are control units, often also referred to as “HMI” (human-machine interface). The control units are usually also operated on said data bus, and are used both for controlling the automation controllers and for controlling the automation components. Frequently, however, the automation components cannot be controlled directly, which means that in such cases (and in the case of many arrangements in principle) the data interchange takes place between the control unit and that automation controller with which the relevant automation component is associated. In complex, widely ramified automation systems, a plurality of control units and often also a plurality of automation controllers are usually used, with automation components being associated with control units usually such that a user of a control unit has visual contact with an automation component which is to be controlled; this applies particularly for actuators which can be used to move machines or tools, and also for other “safety-relevant” fields of use.
In the event of a fault, the display devices of control units can also be used to show status information for the relevant (faulty) automation components. Said information is ideally retrieved directly from the relevant automation component, but is often also retrieved from a system memory in the automation controller. It is therefore often a simple matter to identify the faulty automation component, because the associated control unit, as stated, is frequently in direct proximity to the respective automation component.
Whereas a status information item which is present in an automation component itself or in an associated automation controller often makes only a “binary” statement regarding whether this automation component is operational, or else not, it is frequently the intention to use suitable maintenance measures to prevent the “fault situation” from arising in the first place. An attempt is thus made to use status information and to use empirical values, for example an MTBF (Mean Time Between Failure) value, to identify automation components which, although currently (still) working satisfactorily, need to be maintained before long in order to ensure fault-free continued operation of the automation system. For this purpose, it is customary to transmit operating and status information relating to the automation components to a central maintenance component, which is also called a “diagnosis station” or “maintenance station” on a regular basis. Often, “maintenance stations” of this kind are products from manufacturers other than the manufacturer of the actual automation system, and are then also referred to as an “MES system” (Manufacturer Execution System). These are usually a central workstation computer, in which the operating and status information of many or all automation components is captured centrally and is respectively related to other data (for example the aforementioned MTBF values). This is used by the “maintenance station” to generate and output maintenance instructions, these usually being read and noted or printed and then “executed” by a service employee.
A drawback found with the stated method for creating and processing maintenance information is that the service employee needs to write down or print the centrally available information (maintenance instructions, technical data) and carry it with him, but has no access to the full data inventory of the “maintenance station” “in situ” at the automation component which is to be maintained. This is a drawback particularly with complex automation systems, because the arrangement of the individual automation components is frequently confusing, which means that it is already difficult to locate (find) an affected automation component in the first place. A further drawback is that the “information” available in the “maintenance station” is frequently too complex to write down or print comprehensively.
To overcome the stated drawbacks, various approaches are already known, for example producing the “maintenance station” as a mobile appliance (for example as a laptop computer or PDA, etc.). However, this has the drawback—inter alia—that the service employee needs to carry a possibly sensitive and heavy appliance of this kind with him, which, particularly in a “harsh” industrial environment, can also entail further technical problems. Another way of avoiding the drawbacks is to operate a multiplicity of “maintenance stations” in a ramified automation arrangement, in the hope of one of these “maintenance stations” being near to an automation component which is to be maintained. This solution naturally entails increased complexity for hardware and software.